The WINDOWS driver model (WDM) is a driver technology developed by the MICROSOFT Corporation that supports drivers which are compatible for WINDOWS 98, 2000, ME AND XP. WDM allots some of the work of the device driver to portions of the code that are integrated into the operating system. These portions of code handle low-level buffer management, including direct memory access (DMA) and plug-n-play (PnP) device enumeration.
A DRIVER_OBJECT data structure, corresponding to a single loaded device driver according to WDM, contains a table of function pointers referred to as the dispatch table. The numerical values used to index into the table, namely to find specific functions, are called function codes and are given symbolic names that refer to a type of input/output (IO) such as READ and WRITE or refer to other requests such as CREATE, DEVICE_CONTROL and PnP.
The function located in the table at the corresponding index is expected to implement logic for carrying out such an IO request. The operating system delivers IO request packets (IRPs) to these functions. The operating system also, for each IRP, identifies the device for which the request is intended, in the form of a DEVICE_OBJECT data structure. Such a DEVICE_OBJECT was previously initialized by the driver and represents a single device handled (driven) by the driver. A driver defines its own dispatch functions and inserts them into the dispatch table in its DRIVER_OBJECT at the time the driver initializes itself.
A device node (devnode) is the context (set of data structures and configuration storage) representing a single device within a WDM operating system. If the device is active (connected and enabled for use), then (in the kernel) such a context will include a stack of device object structures, typically one per driver in the layered driver architecture for that type of device. By convention, stacks are said to be built from the bottom up (with the device being below the bottom of the stack) and dismantled from the top down. It is noted that being lower in the stack connotes being closer in terms of directness of communication to the device, while higher connotes being farther away.
Device objects (DOs) in the stack fall into one of three categories. The bottom-most device object is created by the driver for the bus that provides access to the device and is called the physical device object (PDO). The bus driver provides raw communications capability to the device, but little in the way of higher-level device-specific functionality.
Typically a function device object (FDO) is created by a driver which provides access to device-specific and higher-level capabilities of the device. An FDO will be located higher in the device stack than a PDO. In addition to the PDO and FDO, there may optionally be one or more filter device objects (FiDOs). Such FiDOs may be located in the device stack between the PDO and FDO, or above the FDO.
FIG. 1 is a software block diagram that illustrates the layered relationships of objects according to the WDM architecture. Such a WDM architecture 100 includes a device 102 and a bus 104 to which the device 102 is physically connected. A host computing device 105 is also connected to the bus 104. The host 105 includes a variety of software such as an enumerator of bus devices (hereafter DO enumerator) 110, application 106, a PnP manager 108, a bus function driver 112, and a device function driver 116. It is noted that there also may be one more lower filter drivers and one or more upper filter drivers or none at all.
When a device 102 is connected to a bus 104, the bus driver 112 notifies the operating system of a change on the bus. The operating system, i.e., the PnP manager 108, issues a query to the bus 104 via an IRP sent downward in the layered architecture instructing the bus function driver 112 to discover (or enumerate) the devices currently connected to the bus 104. In response to this query, the bus function driver 112 generates PDOs for any newly-connected/discovered devices and provides a set of pointers to the newly-generated PDOs as well as previously-existing PDOs (corresponding to previously albeit currently connected devices). Strictly speaking, the set of DOs represented by the returned pointers are not PDOs until the operating system, namely the PnP manager, examines the set and becomes aware of these DOs.
The PnP manager 108 locates and loads into volatile memory (if not already loaded) the function driver and any filter drivers for the newly-connected devices. It then gives each filter driver and/or function driver an opportunity to create and attach corresponding FiDOs or FDOs to the stacks rooted in the new PDOs, respectively. Ultimately, an application 106 can access a device 102 i.e., consume the functional abilities of the device 102, by passing IRPs through the stack.
When the device is to be disconnected or disabled, the stack must be destroyed. From the top down, under the coordination of the PnP manager 108, each driver detaches its device object from the stack and deletes it.
More detail is provided in FIG. 5, which is a sequence diagram according to the unified modeling language (UML) principles. The sequence 500 in FIG. 5 depicts the various interactions between the device 102, the bus 104, the bus driver 112, the PnP manager 108, the device lower filter driver 114, the device function driver 116, the device upper filter driver 118 and the application 106. The device 102 connects to the bus 104 at message 518. The bus 104 then notifies the bus driver 112 of a change in connected devices at message 520. The bus driver 112 notifies the PnP manager 108 of a change in connected devices at message 522. The PnP manager 108 queries the bus 104 to obtain a set of connected devices via message 524, e.g., an IRP, to the bus driver 112. If not already known by the bus driver 112, then the bus driver 112 queries the bus 104 to discover the connected devices via the query message call 526. The bus driver 112 creates PDOs for newly discovered devices and returns pointers to (addresses of) all PDOs representing devices connected to the bus to the PnP manager 528.
Upon receiving the set of PDOs, the PnP manager enters a loop 530 by which it handles any PDO in the set of which the PnP manager was not previously aware. At message 532, the PnP manager passes one of the PDOs to any device lower filter drivers 114 that might be present. In response, each device lower filter driver attaches a new FiDO to the corresponding stack 128 (see legend 534 in FIG. 5). Then the PnP manager 108 passes the PDO to the device function driver 116, at message 536.
In response, the device function driver 116 attaches a new, named FDO to the device stack 128 and correspondingly registers device-class interfaces (see legend 538) by which consumers can access the device stack. Next, the PnP manager 108 passes the PDO to any device upper filter drivers 118, at message 540. In response, each device upper filter driver 118 attaches a new FiDO 126 to the device stack 128 (see legend 542). Lastly, the PnP, manager 108 notifies applications 106 of the availability of the new device 102, at message 544. In response, the applications 106 may utilize (consume the services of) the device 102 (see legend 546).
Returning to FIG. 1, a stack 134 for the bus 104 is depicted. The stack 134 includes a PDO for the bus 130 (generated by the bus DO enumerator 110) and a bus FDO 132 (generated by the bus function driver 112).
A stack 128 for the device 102 has also been created. The stack 128 includes a PDO 120 (generated by the bus function driver 112), and (possibly) a FiDO 122 (generated by the optional device lower filter driver 114, if present), an FDO 124 (generated by the device function driver 116) and (possibly) a FiDO 126 (generated by the device upper filter driver 118, if present). In other words, if the device lower filter driver 114 and/or the device upper filter driver 118 are not present, then the FiDO 122 and/or the FiDO 126 will not be present, respectively.
In a storage area network (SAN), a device (not depicted) can be sub-divided into smaller units representing different functions, known as logical units (LUNs). Device 102 may be such a LUN. A device or LUN can represent a type of massive non-volatile storage, configuration functionality, monitoring functionality and/or mechanical functionality (such as tape changing), etc. The host 105 can have an application 106 that stores data to, reads data from and/or otherwise utilizes the functionality of device 102, i.e., consumes the services of the device 102. In some SANs, there can be multiple non-volatile memory devices or other devices 102, some of which the host 105 might not have permission to access.
Control over access to certain ones of the devices 102 (also known as LUN masking) has been implemented within the bus driver 112 according to the Background Art. Given the many different types of buses 104 and corresponding drivers 112, the resulting variety of control techniques embedded within the various drivers 112 is unwieldy unless the various bus vendors 104 agree to and abide by a standardized mechanism within the bus driver 112. Such cooperation has not been forthcoming.
A filter driver code arrangement (on a computer-readable medium for use in a system having a bus, a host connected to the bus and one or more devices connected to the bus), which prevents access by the host to any of the devices for which the host does not have respective access permission. Such a filter driver includes: an intercept code portion to intercept a set of data identifying one or more devices connected to the bus, respectively; a determination code portion to determine, based upon the data set and a permission set representing permission relationships between the host and the one or more devices, whether the host has permission to access each of the one or more devices; and a change code portion to change the data set to block access by the host to any of the one or more devices for which the host does not have access permission.
Additional features and advantages of the invention will be more fully apparent from the following detailed description of example embodiments, the appended claims and the accompanying drawings.